Feat/seedless refresh token #15
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> When the user vault is decrypted and there is an attempt to restore an unsupported/deprecated/faulty keyring there's no mechanism to remove related metadata, which leads to a situation where no further action can be made on the controller, because checks for keyrings and metadata length will fail. We could remove the related metadata object when the keyring restore fails, but then we would lose the original ID generated for the keyring. We can, instead, change the place where the metadata is stored from a state property to the encrypted vault: by placing the metadata along with its serialised keyring in the vault we can guarantee a 1:1 link between them while being able to keep metadata for unsupported keyrings. Given that we don't need to use the KeyringController state to persist metadata anymore (as it is persisted along with the vault), we can also remove `keyringsMetadata` completely, and add a `metadata` attribute to each keyring in `state.keyrings` instead - which won't be persisted, as it will be recreated at runtime every time the vault is decrypted and the keyrings are deserialised. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> * Fixes MetaMask#5701 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Mark Stacey <[email protected]>
MetaMask#5788) ## Explanation This PR moves a changelog entry from **13.0.0** to **Unreleased** for `@metamask/profile-sync-controller`. This entry was mistakenly placed in an already released version's changelog. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation This is a RC for v393.0.0. See changelog for more details - `@metamask/[email protected]` ## References Instructions for client migration are in these test drive PRs: - ✅ Extension test drive PR: MetaMask/metamask-extension#32572 - ✅ Mobile test drive PR: MetaMask/metamask-mobile#15211 ## Changelog ```ms ### Changed - Bump `@metamask/profile-sync-controller` from `^13.0.0` to `^14.0.0` ([MetaMask#5789](MetaMask#5789)) ``` ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation When simulating gas for type-4 transactions, use `gasLimit` rather than `gasUsed` from simulation response. ## References ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
Patch release of `@metamask/transaction-controller`.
## Explanation Releasing new versions of @metamask/bridge-controller and @metamask/bridge-status-controller to rename `bridgePriceData` to `priceData` <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation Draft integration for extension: MetaMask/metamask-extension#32722 Sentry Dashboard: https://metamask.sentry.io/dashboard/131851/?statsPeriod=1d <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation When the quote request polling is cancelled, the quote request metadata fields in state don't get reset, which can cause polling to stop prematurely on clients. <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> Fixes MetaMask/metamask-extension#32800 Related to https://consensyssoftware.atlassian.net/browse/MMS-2435 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation Releasing these package versions to enable performance tracing functionality - @metamask/bridge-controller @ 24.0.0 - @metamask/bridge-status-controller @ 20.1.0 Draft PR for extension: MetaMask/metamask-extension#32722 <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
Dependent on: - MetaMask#5725 ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> It is no longer possible to persist duplicates in the vault, though users that already have duplicates will see them in the accounts list, and won't be able to do any action with their vault. These changes aim to discard duplicates, moving the keyring including a duplicate account to the unsupported array. Can be tested on extension with MetaMask/metamask-extension#32621 ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Mark Stacey <[email protected]> Co-authored-by: Charly Chevalier <[email protected]>
…taMask#5792) ## Explanation Add feature flag to configure incoming transactions polling interval remotely. ## References ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
Releasing KeyringController Sev1 fixes. As they are breaking changes, the release inflated across multiple interdependent packages. See changelogs for more info.
…sk#5804) ## Explanation This improves how we perform state updates in the TokenListController. It reduces the mobile commits/renders from 27-30 commits down to 10-15. Here is a test-drive mobile PR: MetaMask/metamask-mobile#15330 | Before | After | |--------|--------| |  |  | ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
…circuit breaker (MetaMask#5798) ## Explanation This PR improves the handling of HTTP status codes in the RPC service by properly handling 405 (Method Not Allowed) and 429 (Too Many Requests) responses without triggering the circuit breaker. ### Changes - Added handling for 405 status code, RPC Error code -32601 (Method not found) - Added handling for 429 status code, RPC Error code-32005 (Request rate limit exceeded) ### Why Previously, these status codes would trigger the circuit breaker, which could lead to unnecessary failover to backup endpoints. These status codes represent expected error conditions that should be handled gracefully without triggering the circuit breaker. ### Testing - [ ] Test with 405 response to verify proper error handling - [ ] Test with 429 response to verify proper error handling and retry delay information - [ ] Verify circuit breaker is not triggered for these status codes ## References * Fixes MetaMask#5766 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation Support additional debug data in `x-metamask-clientproduct` header in incoming transaction requests to accounts API. Provided via optional `tags` in calls to `updateIncomingTransactions`, and optional `client` in constructor. ## References Fixes [MetaMask#4902](MetaMask/MetaMask-planning#4902) ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation An error case was added to our network middleware long ago to workaround load balancer errors that we encountered with Infura at the time. These errors were fixed long ago, so this workaround is no longer needed. I checked with the Infura team, and they confirmed that this case should no longer be possible for Infura RPC endpoints. Removing this check allowed me to update how we're parsing the response body as well. We're now using `response.json()` rather than parsing the raw body as text. As a consequence of this, we no longer have the raw text to attach to parsing errors, but this seems OK to remove given that we don't reference it anywhere, and the full response can be seen in devtools in a development environment. ## References This workaround was originally introduced here: https://github.com/MetaMask/eth-json-rpc-infura/blame/7871c8ee5acf6c738b6bfa43dfaadc02d7f00509/src/index.js#L13C52-L13C59 ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
…5799) ## Explanation `getNativeAssetForChainId` returns the assetId for SOL instead of a recognized native token address. This can cause duplicate SOL tokens to appear in the clients. This updates the address to the ZeroAddress, which clients use for native assets <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation Bump @metamask/bridge-controller to 25.0.1 to release MetaMask#5799 <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation The "create-service-policy" utility (specifically the circuit breaker) has been updated to handle fetch errors rather than RPC errors. This utility was recently updated to handle the JSON-RPC "Internal error" response, but this is only expected for one specific place where this utility is used (the RPC service). Additionally, there remained some cases that would still inappropriately trigger the circuit break policy (i.e. there were some "internal errors" that don't indicate service failure). The utility will now consider all network errors and HTTP 5XX errors as indicative of service failure. HTTP 4XX errors will no longer trigger the circuit breaker. To accomodate these changes, the RPC service now only handles the fetch request and response parsing inside the policy execution phase. The step where errors are parsed and converted to JSON-RPC errors has been moved to _outside_ the execute step. Effectively this has the same functional result for users of the service, but it makes the policy much simpler. ## References Related: * MetaMask#5798 * MetaMask#5766 ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation Minor release of `network-controller` and `controller-utils` ## References See diff ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Salah-Eddine Saakoun <[email protected]>
## Explanation Throw the correct error code from `addTransaction` if an EIP-7702 upgrade is rejected. ## References Relates to [#32956](MetaMask/metamask-extension#32956) ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
…sactionGasFees` method is called with `userFeeLevel` (MetaMask#5800) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> This PR aims to add automatic update `txParams` gas values when controller `updateTransactionGasFees` method is called with `userFeeLevel`. Making this change will give us cleaner logic in the clients since controller does that update. Fix in action: https://github.com/user-attachments/assets/a0ffcee9-e105-406c-a454-0d31907b73ff ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> * Related to : https://github.com/MetaMask/metamask-mobile/pull/15234/files#r2086343114 * Fixes: MetaMask/MetaMask-planning#4897 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [X] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [X] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Matthew Walsh <[email protected]>
Minor release of `@metamask/transaction-controller`.
## Explanation This removes some checks in the `SelectedNetworkController` which disallow a Snap from using their own network, and default to the globally selected network. After this change, Snaps will be able to select their own network just like websites. ## References Related to MetaMask/MetaMask-planning#2938. ## Changelog <!-- If you're making any consumer-facing changes, list those changes here as if you were updating a changelog, using the template below as a guide. (CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or FIXED. For security-related issues, follow the Security Advisory process.) Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods). If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes. Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None". --> ### `@metamask/selected-network-controller` - **CHANGED**: Allow Snaps to change own network ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've highlighted breaking changes using the "BREAKING" category above as appropriate
…n ID (support for devnet chains) (MetaMask#5756) ## Explanation 1. Removes the Solana mainnet filtering 2. Reorganizes data structure to support an account[] -> chain[] -> transactions ``` nonEvmTransactions: { [accountId: string]: { [chain: string]: TransactionStateEntry; }; }; ``` 3. Updates logic to reflect these changes ## References Extension PR with this package preview and working solution: - MetaMask/metamask-extension#32858 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Charly Chevalier <[email protected]>
…stic-permission + @metamask/multichain-api-middleware (MetaMask#5817) ## Explanation Update @metamask/api-specs version to v0.14.0 in: `@metamask/chain-agnostic-permission` `@metamask/multichain-api-middleware` `@metamask/multichain` - to be deprecated soon ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## @metamask/chain-agnostic-permission ## [0.7.0] ### Changed - Bump `@metamask/api-specs` to `^0.14.0` ([MetaMask#5817](MetaMask#5817)) - Bump `@metamask/network-controller` to `^23.5.0` ([MetaMask#5765](MetaMask#5765), [MetaMask#5812](MetaMask#5812)) - Bump `@metamask/controller-utils` to `^11.8.0` ([MetaMask#5765](MetaMask#5765), [MetaMask#5812](MetaMask#5812)) ## @metamask/multichain-api-middleware ## [0.3.0] ### Changed - feat: Add more chain-agnostic-permission utility functions from sip-26 usage ([MetaMask#5609](MetaMask#5609)) - Bump `@metamask/chain-agnostic-permission` to `^0.6.0` ([MetaMask#5715](https://github.com/MetaMask/core/pull/5715),[#5760](https://github.com/MetaMask/core/pull/5760)) - Bump `@metamask/api-specs` to `^0.14.0` ([MetaMask#5817](MetaMask#5817)) - Bump `@metamask/controller-utils` to `^11.9.0` ([MetaMask#5765](MetaMask#5765), [MetaMask#5812](MetaMask#5812)) - Bump `@metamask/network-controller` to `^23.5.0` ([MetaMask#5765](MetaMask#5765), [MetaMask#5812](MetaMask#5812)) ## @metamask/multichain ## [4.1.0] ### Changed - Bump `@metamask/api-specs` to `^0.14.0` ([MetaMask#5817](MetaMask#5817)) - Bump `@metamask/controller-utils` to `^11.9.0` ([MetaMask#5583](MetaMask#5583), [MetaMask#5765](MetaMask#5765), [MetaMask#5812](MetaMask#5812)) ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation bridge-api responses are ignored if they fail schema validation. This can cause issues like - not showing quotes to the user - tx statuses getting stuck due to dropped status updates This PR adds error logging that we can monitor on Sentry. Here's an example trace that includes validation errors: https://metamask.sentry.io/insights/frontend/summary/trace/f058862e687a4946a72377f7fc6b6c1f/?node=txn-1e62b796f286424ea5f1635cd84564b7&project=273496&query=transaction.op%3Acustom&referrer=performance-transaction-summary&source=performance_transaction_summary&statsPeriod=5m×tamp=1747356475&transaction=Bridge%20Quotes%20Fetched&unselectedSeries=p100%28%29&unselectedSeries=avg%28%29 <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation This is the release candidate for version `402.0.0`, it includes the following packages: - `selected-network-controller` - `multichain-transactions-controller` ## References * Related to MetaMask#5756 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Antonio Regadas <[email protected]>
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> This PR aims to fix where the `addTransaction` function incorrectly identifies a transaction as a `simpleSend` type when the recipient is a smart account. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> * Fixes MetaMask/MetaMask-planning#4920 * Extension PR: MetaMask/metamask-extension#33013 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [X] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation # NFT Metadata URL Safety: Moving Phishing Detection from UI to Controller ## Overview This PR implements security enhancements by moving NFT metadata URL safety checks from the UI layer to the controller level. It ensures potentially malicious URLs in NFT metadata are detected and filtered before reaching the UI components. ## Changes - Added URL safety scanning to the `NftController` that checks all external links in NFT metadata - Implemented phishing detection using `PhishingController`'s URL scanning capability - Added caching mechanism to reduce redundant URL checks - Implemented concurrent URL processing with controlled batch sizes - Added sanitization of NFT metadata to remove unsafe URLs ## Technical Details - Added a new method `#sanitizeNftMetadata` that checks all URLs in metadata - Added URL safety check implementation with `PhishingController` integration - Modified `_getNftInformation` to sanitize metadata after retrieval - Implemented filtering for various URL types (image, animation, external links) - Added safety configuration with allowed protocols and denied domains <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References This PR addresses removing the check client side during rendering as we no longer use client side detection for EPD in mobile MetaMask/metamask-mobile#15361 <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Elliot Winkler <[email protected]>
## Explanation Bump eth-json-rpc-infura package to 10.2.0 that includes infura support for sei-mainnet and sei-testnet. ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation Preference-Controller release to add new preference `dismissSmartAccountSuggestionEnabled`. ## References * Related to [#67890](MetaMask/MetaMask-planning#4807) ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [X] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [X] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? N/A * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? N/A * If you had to upgrade a dependency, why did you do so? --> The new defi positions feature is missing a way to track the count of defi positions This PR adds the ability to optionally pass metric tracking function to the DeFi position controller ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Bernardo Garces Chapero <[email protected]>
Currently, when NetworkController is instantiated with pre-existing state that contains an invalid `selectedNetworkClientId` — that is, no RPC endpoint exists which has the same network client ID — then it throws an error. This was intentionally done to bring attention to possible bugs in NetworkController, but this has the unfortunate side effect of bricking users' wallets. To fix this, we now correct an invalid `selectedNetworkClientId` to point to the default RPC endpoint of the first network sorted by chain ID (which in the vast majority of cases will be Mainnet). We still do want to know about this, though, so we log the error in Sentry.
…oller' into feat/seedless-multi-srp
…at/seedless-onboarding-password-sync
…ord-sync' into feat/toprf-sdk-update
tuna1207
force-pushed
the
feat/seedless-refresh-token
branch
from
c536cd3 to
f545879
Compare
tuna1207
changed the base branch from
main
to
feat/seedless-onboarding-password-sync
tuna1207
changed the base branch from
feat/seedless-onboarding-password-sync
to
feat/toprf-sdk-update
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
Add refresh token and revoke refresh token handling to SeedlessOnboardingController
References
Changelog
Checklist